Model-based Quality Management

The paper describes an extension of PROSPEC, a system to represent enterprises model-based to derive from the “deep” knowledge of the business processes requirements for a Quality Management System. Especially, features demanded by the new ISO 9000:2000 for such systems such as continuos improvement and determination of customer requirements are addressed. The development of the enterprise model is guided by process templates and questionnaires to achieve a complete model that can be checked for completeness and integrity by knowledge-based techniques. This model supports also maintenance and continuos improvement. INTRODUCTION Developing a quality management system (QMS) is a tedious task especially for small and medium enterprises that cannot effort specialists for this task. Moreover, updating the QMS regularly to optimize the processes and to make the system reflect the actual practice of the enterprise is even more burdensome. Therefore, computer supported development and maintenance of a QMS is of great promise. However, the construction and maintenance work should not be regarded as a isolated task. Information flow and document handling is a task that is usually also be managed with information technology. Other tasks such as environmental management (ISO 14000) and resource management are also closely related to QM so that an integrated view on all these tasks should be prevalent. There are some tools applicable for supporting the development task. These are mainly drawing tools and tools to select from existing text blocks to facilitate the developing of a quality handbook. This is an approach to facilitate the certification process of ISO 9001 but for the internal quality management, this approach is rather incomplete. Since the quality management approach of ISO 9000 relates closely with business process reengineering (BPR), tools for BPR can also support QM. American institutions such as the Department of Defense (DoD) or the National Institute for Standardization (1) propose the IDEF0 language as a tool to model processes. However, this language’s syntax does not distinguish between entities such as processes, activities, data, organizational units, and resources. Thus it may be used to analyze and design processes, but there is no possibility to support automatic consistency checking. More sophisticated tools such as ARIS-toolkit (2) enables a user to specify processes from different views (data, services, functions) where rules describe which entities must occur in a model and which relations may exist between entities. In this case, a program can check the consistency of a model. However, ARIS does not integrate QM issues yet. We have developed PROSPEC, an Internet-based tool to specify business processes (3). PROSPEC that is realized as a Java applet allows the graphical construction of process models and the storing of a model in a formal language. This tool is now extended to model QM related issues such as responsibility for functions, QM-instructions, and more. PROSPEC checks the completeness and the consistency of a developed enterprise model by means of model-based techniques from AI (4). Finally, PROSPEC shall be extended to support continuous improvement of processes by learning and optimization techniques from AI. These tasks rely on measuring the performance of actual processes and the reasoning on causal dependencies. The formal language to describe enterprise models is realized with XML. XML allows the definition of different views on a knowledge structure, which can be used to distinguish views such as a control view, a quality management view, a resource view, or an information management view. By defining a “deep” knowledge-based view of a process, which includes especially causal and temporal dependencies between entities of a process, PROSPEC allows consistency checking of quality-related issues and intelligent reasoning about requirements. MODEL-BASED REASONING First expert systems (so-called first generation) were based on the representation of rules of thumb to model the experience of experts. This approach is rather application-dependent which would mean for QMS that heuristic knowledge must be modeled for each individual system anew. Although this approach was often successful many researchers and practitioners recognized drawbacks of such systems and proposed second generation expert systems. These systems incorporate a deeper model of knowledge enabling the reasoning by first principles. The deep model consists of the representation of components, causal and other dependencies between components, and the expected correct behavior of the system. A typical application field is diagnosis of technical devices. In contrast to biological systems (such as a human) which formed the domain of most first generation expert systems, the technical systems are almost completely understood. All components are known and the behavior of the whole can theoretically be predicted from the behavior of the parts. Maintaining technical systems involves diagnosing possible failures and planning actions to repair the system. First generation systems would use heuristics to identify malfunctions and to repair the system. Instead second generation expert systems would try to use first heuristic rules if applicable and if no such knowledge exist they would use the deep model to reason how the failure was caused. The advantages of model-based techniques are as follows: • Pure rule-based systems are brittle in the sense that as soon as situations occur which fall outside the scope of the heuristic knowledge base, they are unable to function at all. In such a situation, second generation systems fall back on search that is not heuristic-driven and therefore potentially very inefficient. However, because these traditional search techniques can theoretically solve a wider class of problems, there is a graceful degradation of performance instead of abrupt failure. • First generation systems base their explanations purely on a backtrace of the heuristic rules that were needed to find a solution. It is well known however, that the path followed to find a solution usually differs from convincing rational argument why the solution is valuable, particularly if a lot of heuristic knowledge entered into the reasoning process. Because second generation expert systems have access to a deeper understanding, they are capable to formulate a deeper and more convincing explanation, which goes beyond the mere recall of which rules fired. • The most important advantage lies however in knowledge acquisition. Finding heuristic rules has turned out to be extremely difficult. Experts typically take a long time to come up with solid rules, the rule set seems never to be complete, is continuously changing and shows inconsistencies across experts. These inconsistencies are apparently due to different experiences which are the source of heuristic rule discovery. Second generation expert systems constitute a major jump forward in technology because they exhibit learning behavior in the sense that they are capable to acquire new heuristic rules. If we adopt the model-based approach for PROSPEC, we must model processes and their parts as well as the interrelations between processes and their components. An important foundation for a model-based approach is an appropriate process model. This model must support • the representation of all parts such as functions, required services and products, produced services and products, required information and resources, and more, • the representation of interrelations between entities such as temporal and causal dependencies between functions and information flow, • different views on the models, and finally • integrity and completeness constraints between entities. In the following we describe part of the model and explain the basics for checking consistency and completeness in such a model. PROCESS GRAMMAR XML (5) is used to define a process grammar and to store enterprise models. XML allows defining a grammar that can be stored somewhere in the Internet in a dtd-file. The further elaboration on the process model shall be no discussion on XML features and syntax. To explain all details of the definition of a grammar would cost too much space here. On the other side, we want to show the full representational capabilities. Therefore we do use XML in an informal style and the following definitions are a mixture of grammar definition and representation with the grammar. XML is a promising standard for describing rich knowledge-based models because it allows defining different views on a model. Thus for an enterprise model we propose a basic control view and building upon it views to explore in deeper detail such aspects as the flow of information, the quality view and a resource view. A process model can be interpreted as graph consisting of nodes and edges between nodes. Nodes represent such entities as • functions (main activities of the process, test activities, and decisions), • events (typically, events occur asynchronously and they are conditions for further performance of functions), • information that is used by different functions. Edges represent a flow of control and the flow of information between functions. Thus, an enterprise consisting of at least one process is defined as follows: enterprise ::= name process+. process ::= (function | event | information)+ (control-flow | information-flow)*. The plus sign in the definition means that at least one element must exist (an enterprise must have a process and at least one node). The asterisk means that zero or more elements may exist (in a very simple process no control flow must be defined). The ‘|’ in the definition means a disjunction (a node may be a function, an event, or information). This process-oriented model could be easily extended with an organizational chart by adding an appropriate attribute to the enterprise definition. The main view of any process model is a control view that describes the sequence of activities (functions) and events as well as the causal and temporal dependencies between these entities. Since processes may become very complex, it should be possible to describe processes on different levels of granularity. Thus in an abstract process it possible to link to a refined subprocess. The quality view focuses besides other aspects on the fulfillment of customer requirements. Processes and single functions are performed to produce certain products or services for the client of the process. These services are outputs of a process. On the contrary, processes may also require certain inputs that are also products or services. For most functions as well as processes a single authority (a human or an organizational unit) should be responsible which must be described in a QMS. Further attributes of any function or process are a name, an expected duration for performing it, a number of instructions that may give a framework how to perform the action. Since we may refer to entities in relations described later, it is necessary to give entities a unique identifier. Thus, we assume PROSPEC gives unique names to every defined object (node). While we use graphical elements (e.g. edges) in the user interface to describe relations, the formal language needs these unique identifiers to store information. In the following definitions we use the id attribute for XML elements to store this identifiers and the idref attribute of XML is used to reference these objects later. We assume a further classification of such references where the first character of the name is an abbreviation for object’s type and the rest of the name is a unique number represented in the definitions as ‘X’. function ::= procedure | test | decision | subprocess. procedure ::= functional-descr. test ::= duration. decision ::= authority, decisionstatement. subprocess ::= functional-descr. functional-descr ::= name duration instruction* input* output* information* responsibility* resource*. instruction ::= text input ::= (service | product) output ::= (service | product) service ::= name service-req*. product ::= name product-req*. product-req ::= value . service-req ::= value . event ::= name duration. information ::= dataObject | document. dataObject ::= name super? attribute* . document ::= url. responsibility ::= authority | position. authority ::= name. position ::= name. resource ::= name resource-type. control-flow ::= (temporal-relation | causal-relation). temporal-relation ::= event-ref function-ref | function-ref function-ref | function-ref event-ref. causal-relation ::= event-ref function-ref | function-ref function-ref | function-ref event-ref | information-flow ::= function-ref dataObject-ref | function-ref dataObject-ref | event-ref dataObject-ref function-ref | function-ref dataObject-ref function-ref If an enterprise is modeled with PROSPEC (with the graphical user interface), the model can be stored in the described grammar. The internal model used to reason about the model is of course optimized. We may use real references (pointers) instead of unique identifiers and whole program is object-oriented (with Java). However, the process grammar must contain all information to rebuild a formerly developed model by reading it from a file. If a user has specified a process or a whole enterprise model, a completeness check can be started. For reasoning about the completeness, the process is compared with a standard process. For the standard process defined also in XML, it is expected that it has an output delivered to a customer or some other process in the enterprise. Thus if no output is specified the developer is asked to define what service or product the process shall output. If the user specifies the output, PROSPEC asks about the customer’s requirements and how they are determined. Typically, the determination of the requirements is modeled by additional functions of the process. These requirements are modeled also in the services or products. In a quality-oriented enterprise, the outputs should also be checked for correctness and satisfaction of the customer’s expectations. This again should be a function (test) visible in the process model. A similar procedure must be performed for the inputs of a process. Furthermore, PROSPEC has to check whether outputs of a process are also declared as inputs of another process. Finally, for all functions it should be specified who performs the function (an organizational unit or a person), who is responsible, and how the performance is done (i.e. by instructions). Thus, the completeness of the process model is checked by comparing it with an idealized standard process behavior. If PROSPEC detects deviations, it asks the user to complete the model or it asks questions from which either the model is completed or explanations are added why the process deviates from the standard behavior. DISCUSSION We have presented a first approach to model-based quality management. Due to space limitations, we have omitted many details (e.g., the process model must also include graphical characteristics to rebuild a graphical model from the stored model). However, there are still important aspects not yet addressed here. The model-based approach as explained earlier builds on the cooperation of deep and heuristic knowledge. Heuristic knowledge should be incorporated by defining additional more specific process types. Such a library of processes can be used to develop first models and to classify processes inserted by a user. Further, we have not yet elaborated the model how the performance of a process is measured in order to improve it (continuously).